Wireless device handover in a wireless network with bearer capabilities

ABSTRACT

A first base station receives from at least one second base station, a first message comprising capability information indicating a number of bearers supported by the at least one second base station. The first base station receives from a wireless device, a measurement report comprising a received power of a cell of the second base station. The first base station determines a handover to the cell based on the measurement report and the number of bearers supported by the at least one second base station. The first base station sends a handover request to the at least one second base station in response to the determining of the handover.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/626,184, filed Feb. 5, 2018, which is hereby incorporated byreference in its entirety.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Examples of several of the various embodiments of the present disclosureare described herein with reference to the drawings.

FIG. 1 is a system diagram of an example communications system as per anaspect of an embodiment of the present disclosure.

FIG. 2 is an example diagram of non-roaming 4G architecture for 3GPPaccesses as per an aspect of an embodiment of the present disclosure.

FIG. 3 is a block diagram of a base station and a wireless device as peran aspect of an embodiment of the present disclosure.

FIG. 4 is an example diagram of policy and charging control architectureas per an aspect of an embodiment of the present disclosure.

FIG. 5 is an example call flow diagrams depicting dedicated beareractivation procedure as per an aspect of an embodiment of the presentdisclosure.

FIG. 6 is an example diagram of a procedure for getting/deriving networkcapability of supported number of bearers, and an initial attachprocedure as per an aspect of an embodiment of the present disclosure.

FIG. 7 is an example diagram depicting an eNodeB handover procedure asper an aspect of an embodiment of the present disclosure.

FIG. 8 is an example diagram depicting an information element of causeapplied over an interface between a PGW and an SGW, and/or an interfacebetween an SGW and an MME as per an aspect of an embodiment of thepresent disclosure.

FIG. 9 is an example diagram depicting an information element of causeapplied over an interface between an eNodeB and an MME as per an aspectof an embodiment of the present disclosure.

FIG. 10 is an example diagram depicting the list of information elementsin an ENB CONFIGURATION UPDATE message comprising an information elementeNodeB bearer capability indicating number of bearer supported as per anaspect of an embodiment of the present disclosure.

FIG. 11A is an example diagram depicting the list of informationelements in an echo request message as per an aspect of an embodiment ofthe present disclosure.

FIG. 11B is an example diagram depicting the information elementdefinition of sending node feature comprised in an echo request messageas per an aspect of an embodiment of the present disclosure.

FIG. 12 is an example diagram depicting the example supported-featuresvalues comprised in a sending node feature information element, and avalue of BEARER CAPABILITY used to indicate the capability of a networkelement as per an aspect of an embodiment of the present disclosure.

FIG. 13 is an example flow diagram of an aspect of an embodiment of thepresent disclosure.

FIG. 14 is an example flow diagram of aspects of an embodiment of thepresent disclosure.

FIG. 15 is an example flow diagram of an aspect of an embodiment of thepresent disclosure.

FIG. 16 is an example flow diagram of an aspect of an embodiment of thepresent disclosure.

DETAILED DESCRIPTION OF EXAMPLES

Example embodiments of the present disclosure enable implementation ofenhanced features and functionalities in 4G systems. More particularly,the embodiments of the technology disclosed herein may relate todifferent capabilities of network elements for supporting number ofbearers. Throughout the present disclosure, UE, wireless device, andmobile device are used interchangeably. Throughout the presentdisclosure, base station, evolved Node B (eNB or eNodeB) are usedinterchangeably.

The following acronyms are used throughout the present disclosure:

4G 4th generation mobile networks

AF Application Function

AMBR Aggregate Maximum Bit Rate

AN Access Network

APN Access Point Name

BBERF Bearer Binding and Event Reporting Function

DPI Deep Packet Inspection

DL Downlink

eNB evolved Node B

eNodeB evolved Node B

EPS Evolved Packet System

E-UTRAN Evolved Universal Terrestrial Radio Access Network

GW Gateway

HSS Home Subscriber Server

IoT Internet of things

LBI Linked EPS Bearer Identity

LGW Local Gateway

MEC Mobile Edge Computing

MME Mobility Management Entity

NAS Non-Access-Stratum

OCS Online Charging System

OFCS Offline Charging System

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Function

PDN Packet Data Network

PGW PDN Gateway

PLMN Public Land Mobile Network

PMIP Proxy Mobile IP

PTI Procedure Transaction Id

RAN Radio Access Network

SGW Serving Gateway

SIPTO Selected IP Traffic Offload

TDF Traffic Detection Function

UE User Equipment

UL Uplink

FIG. 1 is a diagram of an example communications system 100 in which oneor more disclosed embodiments may be implemented. The communicationssystem 100 may comprise a multiple access system configured to providecontent, such as voice, data, video, messaging, broadcast, etc., tomultiple wireless users. The communications system 100 may enablemultiple wireless users to access such content through the sharing ofsystem resources, including, for example, wireless bandwidth. Forexample, communications systems 100 may employ one or more channelaccess processes, such as code division multiple access (CDMA), timedivision multiple access (TDMA), frequency division multiple access(FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and/orthe like.

As shown in FIG. 1, the communications system 100 may comprise wirelesstransmit/receive units (WTRUs) 102A, 102B, 102C, 102D, a radio accessnetwork (RAN) 104, a core network 106, the Internet 110, and/or othernetworks 112. It will be appreciated that the disclosed embodimentscontemplate various numbers of WTRUs, base stations, networks, and/ornetwork elements. Each of the WTRUs 102A, 102B, 102C, 102D may beconfigured to operate and/or communicate in a wireless environment. Byway of example, WTRUs 102A, 102B, 102C, 102D may be configured totransmit and/or receive wireless signals and may comprise user equipment(UE), a mobile station, a fixed or mobile subscriber unit, a pager, acellular telephone, a personal digital assistant (PDA), a smartphone, alaptop, a netbook, a personal computer, a wireless sensor, consumerelectronics, combinations thereof, and/or the like.

The communications systems 100 may also comprise a base station 114Aand/or base station 114B. Each of the base stations 114A, 114B may be atype of device configured to wirelessly interface with at least one ofthe WTRUs 102A, 102B, 102C, 102D to facilitate access to one or morecommunication networks, such as core network 106, Internet 110 and/ornetworks 112. By way of example, base stations 114A and/or 114B maycomprise a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, combinations thereof, and/or the like. While basestations 114A and 114B are each depicted as a single element, it will beappreciated that base stations 114A and 114B may comprise variousnumbers of interconnected base stations and/or network elements.

As illustrated, base station 114A may be a part of the RAN 104, whichmay also comprise other base stations and/or network elements (notshown), such as, for example, a base station controller (BSC), a radionetwork controller (RNC), relay nodes, combinations thereof, and/or thelike. Base station 114A and/or the base station 114B may be configuredto transmit and/or receive wireless signals within a particulargeographic region, which may be referred to as a cell (not shown). Thecell may be further divided into cell sectors. For example, the cellassociated with the base station 114A may be divided into three sectors.Thus, according to an embodiment, base station 114A may comprise threetransceivers, i.e., one for each sector of the cell. According to anembodiment, base station 114A may employ multiple-input multiple output(MIMO) technology and, therefore, may utilize multiple transceivers foreach sector of the cell.

Base stations 114A and/or 114B may communicate with one or more of theWTRUs (e.g. 102A, 102B, 102C, and 102D) over an air interface (e.g.116A, 116B, (116C and/or 116E), and 116D, respectively), which maycomprise a wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). An airinterface (e.g. 116A, 116B, 116C, 116D, 116E, 116F and 116G) may beestablished employing a suitable radio access technology (RAT).

More specifically, as noted above, communications system 100 maycomprise a multiple access system and may employ one or more channelaccess schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, combinationsthereof, and/or the like. For example, base station 114A in the RAN 104and WTRUs 102A, 102B, and 102C may implement a radio technology such asUniversal Mobile Telecommunications System (UMTS) Terrestrial RadioAccess (UTRA), which may establish air interface (e.g. 102A, 102B, and102C) employing wideband CDMA (WCDMA). WCDMA may comprise communicationprotocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA(HSPA+). HSPA may comprise High-Speed Downlink Packet Access (HSDPA)and/or High-Speed Uplink Packet Access (HSUPA).

According to an embodiment, base station 114A and WTRUs 102A, 102B, 102Cmay implement a radio technology such as Evolved UMTS Terrestrial RadioAccess (E-UTRA), which may establish air interface (e.g. 116A, 116B, and116C, respectively) employing Long Term Evolution (LTE) and/orLTE-Advanced (LTE-A).

According to an embodiment, base station 114A and WTRUs 102A, 102B, 102Cmay implement radio technologies such as IEEE 802.16 (i.e., WorldwideInteroperability for Microwave Access (WiMAX)), CDMA1000, CDMA1000 1X ,CDMA1000 EV-DO, Interim Standard 1000 (IS-1000), Interim Standard 95(IS-95), Interim Standard 856 (IS-856), Global System for Mobilecommunications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSMEDGE (GERAN), combinations thereof, and/or the like.

Base station 114B in FIG. 1 may comprise a wireless router, Home Node B,Home eNode B, or an access point, for example, and may utilize a RAT forfacilitating wireless connectivity in a localized area, such as a placeof business, a home, a vehicle, a campus, combinations thereof, and/orthe like. According to an embodiment, base station 114B and WTRUs 102C,102D may implement a radio technology such as IEEE 802.11 to establish awireless local area network (WLAN). According to an embodiment, basestation 114B and WTRUs 102C and 102D may implement a radio technologysuch as IEEE 802.15 to establish a wireless personal area network(WPAN). According to an embodiment, base station 114B and WTRUs 102C and102D may utilize a cellular-based RAT (e.g., WCDMA, CDMA1000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1,base station 114B may have a direct connection to the Internet 110.Thus, base station 114B may not be required to access the Internet 110via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe a type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102A, 102B, 102C, and 102D. For example, core network 106 mayprovide call control, billing services, mobile location-based services,pre-paid calling, Internet connectivity, video distribution, etc.,and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1, it anticipated thataccording to an embodiment, RAN 104 and/or core network 106 may be indirect or indirect communication with other RANs that employ the sameRAT as the RAN 104 or a different RAT. For example, in addition to beingconnected to the RAN 104, which may utilize an E-UTRA radio technology,the core network 106 may also be in communication with another RAN (notshown).

Core network 106 may serve as a gateway for the WTRUs 102A, 102B, 102Cand/or 102D to access the Internet 110 and/or other networks 112. TheInternet 110 may comprise a global system of interconnected computernetworks and devices that use common communication protocols, such asthe transmission control protocol (TCP), user datagram protocol (UDP)and the internet protocol (IP) in the TCP/IP internet protocol suite.Other networks 112 may comprise wired and/or wireless communicationsnetworks owned and/or operated by other service providers. For example,the networks 112 may comprise another core network connected to one ormore RANs, which may employ the same RAT as the RAN 104 or a differentRAT.

Some or all of the WTRUs 102A, 102B, 102C, and 102D in thecommunications system 100 may comprise multi-mode capabilities (i.e.,the WTRUs 102A, 102B, 102C, and 102D may comprise multiple transceiversfor communicating with different wireless networks over differentwireless links).

FIG. 2 is an example diagram of non-roaming 4G architecture for 3GPPaccesses.

E-UTRAN 1005 may be an access network, and may have the function ofHeader compression and user plane ciphering, UL and DL bearer leveladmission control, UE-AMBR enforcement, etc.

MME 1010 may have the function of NAS signaling, mobility management,session management, PDN GW and Serving GW selection, etc.

HSS 1015 may be a database that contains user-related andsubscriber-related information. It may provide supporting functions inmobility management, call and session setup, user authentication andaccess authorization.

SGW 1020 may be a gateway which terminates the user plane interfacetowards the E-UTRAN. It may be the functionality of mobility anchoringfor inter-3GPP mobility, and may have the function of packet routing andforwarding, and accounting for inter-operator charging, etc.

PGW 1025 may be a gateway which terminates the SGi interface towards thePDN. It may comprise the function of per-user based packet filtering (bye.g. deep packet inspection), UE IP address allocation, and policyenforcement (e.g. QoS policy and charging policy enforcement).

PCRF 1030 may be the policy and charging control element. It may makethe QoS policy, charging policy and gating policy and send the policiesto the PCEF (PGW) 1025 for enforcement.

AF 1035 may be the application function, and it may provide theapplication related information to the PCRF 1030 for policy decision.

FIG. 3 is an example block diagram of a base station 301 and a wirelessdevice 306, as per an aspect of an embodiment of the present invention.A communication network 500 may comprise at least one base station 301and at least one wireless device 306. The base station 301 may compriseat least one communication interface 302, at least one processor 303,and at least one set of program code instructions 305 stored innon-transitory memory 304 and executable by the at least one processor303. The wireless device 306 may comprise at least one communicationinterface 307, at least one processor 308, and at least one set ofprogram code instructions 310 stored in non-transitory memory 309 andexecutable by the at least one processor 308. Communication interface302 in base station 301 may be configured to engage in communicationwith communication interface 307 in wireless device 306 via acommunication path that comprises at least one wireless link 311.Wireless link 311 may be a bi-directional link. Communication interface307 in wireless device 306 may also be configured to engage in acommunication with communication interface 302 in base station 301. Basestation 301 and wireless device 306 may be configured to send andreceive data over wireless link 311 using multiple frequency carriers.According to some of the various aspects of embodiments, transceiver(s)may be employed. A transceiver is a device that comprises both atransmitter and receiver. Transceivers may be employed in devices suchas wireless devices, base stations, relay nodes, and/or the like.

FIG. 4 is an example diagram of policy and charging controlarchitecture.

PCEF 1025 may be located in a PGW, and it mainly enforces the policy(e.g. QoS policy, charging policy and gating) received from the PCRF1030. BBERF 1150 may be located in an SGW or non-3GPP access, and it maybe used for PMIP-based S5/S8 or non-3GPP access scenario and enforce theQoS policy received from a PCRF. TDF 1155 may be the traffic detectionfunction and may be used for the application detection with the DPIfunction. OCS 1140 may be the online charging system and may interactwith the PGW 1025 or TDF 1155 to provide the online charging function.OFCS 1145 may be the offline charging system and may interact with thePGW 1025 or TDF 1155 to provide the offline charging function.

Implementation of existing technologies may have issues in whichdifferent network elements may have capabilities that support differentnumbers of bearers. Existing technologies may have issues indicating thecause of a failure when creating a bearer. Example embodiments mayindicate a failure for creating a bearer when the cause(s) of thefailure are due to: (1) exceeding the supported number of bearers,and/or (2) an EPS bearer QoS cannot be supported. Embodiments may usethe cause information to avoid further signaling to create a bearer.

Implementation of existing technologies may have issues indicating acapability to support various numbers of bearers. The capability may bereported using session level and/or bearer level signaling. Exampleembodiments may indicate a capability of a network element to support anumber of bearers by node level signaling.

Implementation of existing technologies have no ability to select aneNodeB for an eNodeB handover based on bearer capabilities. Exampleembodiments may select an eNodeB for an eNodeB handover based oncapability(ies) of supported number of bearers for candidate targeteNodeB(s). The embodiments may be used to select an eNodeB that avoidscommunication interruption during a handover.

Implementation of existing technologies may not have the ability toselect an MME for MME relocation based on bearer capabilities. Exampleembodiments may select an MME for MME relocation based oncapability(ies) of supported number of bearers for candidate target MME.

Implementation of existing technologies not have the ability to selectan SGW for SGW relocation. Example embodiments may select an SGW for SGWrelocation based on capability(ies) of supported number of bearers forcandidate target SGW.

In an example, a PGW may initiate a dedicated bearer creation procedure,an MME may have limited capability to support a new bearer and/or, theMME may have limited capability to support requested QoS. The MME mayindicate a failure to create a bearer with the cause(s) of exceedingsupported number of bearers and/or EPS bearer QoS cannot be supported.FIG. 5 shows an example call flow which may comprise one or moreactions.

A PCRF may send to a PGW a PCC decision provision (QoS policy) message.This may correspond to an initial step of the PCRF-Initiated IP-CANSession Modification procedure or to the PCRF response in the PCEFinitiated IP-CAN Session Modification procedure. In response to themessage received from the PCRF, the PGW may determine to create a newdedicated bearer, and the PGW may use the received QoS policy to assignthe EPS bearer QoS for a bearer, e.g., it may assign the values to abearer level QoS parameters QCI, ARP, GBR and MBR. The PGW may send toan SGW a create bearer request message comprising one or more of thefollowing parameters applied to a bearer: IMSI, Procedure Transaction Id(PTI), EPS bearer QoS, TFT, S5/S8 TEID, charging id, Linked EPS BearerIdentity (LBI), and/or protocol configuration options; wherein the LBImay be the EPS Bearer Identity of the default bearer; the PTI parametermay be used when the procedure was initiated by a UE requested bearerresource modification procedure; the protocol configuration options maybe used to transfer application level parameters between the UE and thePGW, and may be sent transparently through an MME and an SGW.

In response to the message received from the PGW, the SGW may determinewhether it can support creating a new bearer and/or whether it cansupport the EPS bearer QoS. As an example, the SGW may determine whetherit can support creating a new bearer by checking whether number ofbearers has exceeded a configured supported number of bearers if a newbearer is created. In an example, if the SGW determines it cannot tocreate a new bearer, e.g. the number of bearers has exceeded theconfigured supported number of bearers and/or the EPS bearer QoS cannotbe supported, the SGW may send to PGW a response message (e.g. createbearer response) comprising at least one cause information elementindicating failure of creating a bearer because of exceeding supportednumber of bearers and/or EPS bearer QoS cannot be supported; FIG. 8 isan example diagram depicting an information element of cause comprisedin the create bearer response message. As an example, the create bearerresponse message may comprise one cause information element indicatingfailure of creating a bearer because of exceeding supported number ofbearers and/or EPS bearer QoS cannot be supported; as an example, thecreate bearer response message may comprise two cause informationelements (IE), a first IE may be used to indicate the failure ofcreating a bearer because of exceeding supported number of bearers, anda second IE may be used to indicate the failure of creating a bearerbecause of EPS bearer QoS cannot be supported by the SGW. The PGW mayresponse to the PCRF that the PCC rule cannot be enforced, and thefollowing actions in this example are not performed in this case. In anexample, if the SGW determines it can create a new bearer, or the SGWdoes not determine whether it can create a new bearer at this moment,the SGW may send to an MME a create bearer request message comprisingone or more of the following parameters applied to a bearer: IMSI, PTI,EPS bearer QoS, TFT, S1-TEID, PDN GW TEID (GTP-based S5/S8), LBI, and/orprotocol configuration options.

In response to the message received from the SGW, the MME may determinewhether it can support creating a new bearer and/or whether it cansupport the EPS bearer QoS. As an example, the MME may determine whetherit can support creating a new bearer by checking whether number ofbearers has exceeded a configured supported number of bearers if a newbearer is created. In an example, if the MME determines it cannot createa new bearer, e.g. the number of bearers has exceeded the configuredsupported number of bearers and/or the EPS bearer QoS cannot besupported, the MME may send to the SGW, a response message (e.g. createbearer response) comprising at least one cause information elementindicating failure of creating a bearer because of exceeding supportednumber of bearers and/or EPS bearer QoS cannot be supported. FIG. 8 isan example diagram depicting an information element of cause comprisedin the create bearer response message. As an example, the create bearerresponse message may comprise one cause information element indicatingfailure of creating a bearer because of exceeding supported number ofbearers and/or EPS bearer QoS cannot be supported; as an example, thecreate bearer response message may comprise two cause informationelements (IE), a first IE may be used to indicate the failure ofcreating a bearer because of exceeding supported number of bearers, anda second IE may be used to indicate the failure of creating a bearerbecause of EPS bearer QoS cannot be supported by the MME. The SGW maysend to PGW a response message (e.g. create bearer response) comprisingat least one cause information element indicating the failure ofcreating a bearer because of exceeding supported number of bearers ofMME and/or EPS bearer QoS cannot be supported by the MME; and the PGWmay response to the PCRF that the PCC rule cannot be enforced, thefollowing actions in this example are not performed in this case. In anexample, if the MME determines it can create a new bearer, or the MMEdoes not determine whether it can create a new bearer at this moment,the MME may select an EPS bearer identity, which has not yet beenassigned to the UE, and the MME may build a session management requestmessage comprising one or more of the following parameters: PTI, TFT,EPS bearer QoS parameters (excluding ARP), Protocol configurationoptions, the EPS bearer identity, and/or the Linked EPS Bearer Identity(LBI), and the MME may send to an eNodeB a bearer setup request messagecomprising one or more of the following: EPS bearer identity, EPS bearerQoS, session management request message, S1-TEID.

In response to the message received from the MME, the eNodeB maydetermine whether it can support creating a new bearer and/or whether itcan support the EPS bearer QoS. As an example, the eNodeB may determinewhether it can support creating a new bearer by checking whether numberof bearers has exceeded the configured supported number of bearers if anew bearer is created. In an example, if the eNodeB determines it cannotcreate a new bearer, e.g. number of bearers has exceeded the configuredsupported number of bearers and/or the EPS bearer QoS cannot besupported, the eNodeB may send to the MME, a response message (e.g.bearer setup response) comprising at least one cause information elementindicating failure of creating a bearer because of exceeding supportednumber of bearers and/or EPS bearer QoS cannot be supported; FIG. 9 isan example diagram depicting an information element of cause comprisedin the bearer setup response message sending from the eNodeB to the MME.As an example, the bearer setup response message may comprise one causeinformation element indicating the failure of creating a bearer becauseof exceeding supported number of bearers and/or Not supported QCI value;as an example, the bearer setup response message may comprise two causeinformation elements (IE), a first IE may be used to indicate thefailure of creating a bearer because of exceeding supported number ofbearers, and a second IE may be used to indicate the failure of creatinga bearer because of Not supported QCI value. In response to the messagereceived from the eNodeB, the MME may send to SGW, a response message(e.g. create bearer response) comprising at least one cause informationelement indicating the failure of creating a bearer because of exceedingsupported number of bearers of eNodeB and/or EPS bearer QoS cannot besupported by the eNodeB; The SGW may send to PGW a response message(e.g. create bearer response) comprising at least one cause informationelement indicating failure of creating a bearer because of exceedingsupported number of bearers of eNodeB and/or EPS bearer QoS cannot besupported by the eNodeB; and the PGW may response to the PCRF that thePCC rule cannot be enforced, the following actions in this example arenot performed in this case. In an example, if the eNodeB determines itcan create a new bearer, or the eNodeB does not determine whether it cancreate a new bearer at this moment, the eNodeB may map the EPS bearerQoS to Radio Bearer QoS and may send to a UE a RRC connectionreconfiguration message comprising one or more of the followinginformation applied to a bearer: Radio Bearer QoS, session managementrequest, and/or EPS RB Identity.

In response to the message received from the eNodeB, the UE may send tothe eNodeB an RRC connection reconfiguration complete message. If the UEdetermines it may not create a new bearer, e.g. the number of bearershas exceeded the configured total supported number of bearers and/or theRadio Bearer QoS may not be supported, the RRC connectionreconfiguration complete message may comprise at least one causeinformation element indicating failure of creating a bearer because ofexceeding total supported number of bearers and/or Radio Bearer QoScannot be supported.

In response to the message received from the UE, the eNodeB may send tothe MME a bearer setup response message comprising one or more of thefollowing: EPS Bearer Identity, and/or S1-TEID. The message may indicatefailure of creating a bearer by comprising at least one causeinformation element with one or more values. In an example, a firstcause value may be used to indicate the UE rejects a new bearer becauseof exceeding supported number of bearers and/or Radio Bearer QoS may notbe supported. In an example, a second cause value may be used toindicate the eNodeB rejects a new bearer because of exceeding totalsupported number of bearers and/or EPS bearer QoS cannot be supported.The MME may receive this message after the session management responsemessage (sent in following action). If the UE determines it may create anew bearer, the UE NAS layer may build a session management responsemessage comprising the EPS Bearer Identity, and the UE may send to theeNodeB a direct transfer message comprising the session managementresponse message.

In response to the message received from the UE, the eNodeB may send tothe MME an uplink NAS transport (session management response) message.In response to the message received from the eNodeB, the MME maydetermine whether it can support creating a new bearer and/or whether itcan support the EPS bearer QoS. The MME may send to the SGW a createbearer response message comprising one or more of the following: EPSBearer Identity, S1-TEID, and/or User Location Information (ECGI). Thecreate bearer response message may indicate failure of creating a bearerby comprising at least one cause information element with one or morevalues. In an example, a first cause value may be used to indicate theUE rejects a new bearer because of exceeding supported number of bearersand/or Radio Bearer QoS cannot be supported. In an example, a secondcause value may be used to indicate the eNodeB rejects a new bearerbecause of exceeding supported number of bearers and/or EPS bearer QoScannot be supported. In an example, a third cause value may be used toindicate the MME rejects a new bearer because of exceeding supportednumber of bearers and/or EPS bearer QoS cannot be supported. As anexample, FIG. 8 depicts a cause information element comprised in thecreate bearer response message.

In response to the message received from the MME, the SGW may determinewhether it can support creating a new bearer and/or whether it cansupport the EPS bearer QoS. The SGW may acknowledge the beareractivation to the PGW by sending a create bearer response comprising oneor more of the following: EPS Bearer Identity, S5/S8-TEID, and/or UserLocation Information (ECGI). The message may indicate failure ofcreating a bearer by comprising at least one cause information elementwith one or more values. In an example, a first cause value may be usedto indicate the UE rejects a new bearer because of exceeding supportednumber of bearers and/or Radio Bearer QoS cannot be supported. In anexample, a second cause value may be used to indicate the eNodeB rejectsa new bearer because of exceeding supported number of bearers and/or EPSbearer QoS cannot be supported. In an example, a third cause value maybe used to indicate the MME rejects a new bearer because of exceedingsupported number of bearers and/or EPS bearer QoS cannot be supported.In an example, a fourth cause value may be used to indicate the SGWrejects a new bearer because of exceeding supported number of bearersand/or EPS bearer QoS cannot be supported. As an example, FIG. 8 depictsa cause information element comprised in the create bearer responsemessage.

In response to the message received from the SGW, the PGW may send tothe PCRF a response message indicating whether the requested PCCdecision (QoS policy) could be enforced or not, allowing the completionof the PCRF-Initiated IP-CAN Session Modification procedure or the PCEFinitiated IP-CAN Session Modification procedure. The message mayindicate failure of creating a bearer by comprising at least one causeinformation element with one or more values. In an example, a firstcause value may be used to indicate the UE rejects a new bearer becauseof exceeding supported number of bearers and/or Radio Bearer QoS may notbe supported. In an example, a second cause value may be used toindicate the eNodeB rejects a new bearer because of exceeding supportednumber of bearers and/or EPS bearer QoS cannot be supported. In anexample, a third cause value may be used to indicate the MME rejects anew bearer because of exceeding supported number of bearers and/or EPSbearer QoS cannot be supported. In an example, a fourth cause value maybe used to indicate the SGW rejects a new bearer because of exceedingsupported number of bearers and/or EPS bearer QoS cannot be supported.In an example, a fifth cause value may be used to indicate the PGWrejects a new bearer because of exceeding supported number of bearersand/or EPS bearer QoS cannot be supported.

The PCRF may take action(s) and/or make policy decision(s) based on theinformation received from the PGW. As an example, the PCRF may send tothe PGW a message to remove some (e.g. low priority) PCC rules, the PGWmay remove the related bearer accordingly. As an example, the PCRF maysend to an AF a message comprising an information element indicatingfailure of creating a bearer for the service of AF.

In an example, an MME may derive/get network capability of supportednumber of bearers by node level signaling with eNodeB and SGW, and theMME may send to a UE the network capability of supported number ofbearers when UE attached to the network. FIG. 6 shows an example callflow which may comprise one or more of the following actions:

An MME may receive from an eNodeB, a node level message comprising aninformation element indicating eNodeB capability of supported number ofbearers as per eNodeB. As an example, the MME may receive from theeNodeB an ENB CONFIGURATION UPDATE message comprising an informationelement indicating eNodeB capability of supported total number ofbearers. FIG. 10 is an example diagram depicting a list of informationelements in an ENB CONFIGURATION UPDATE message comprising aninformation element eNodeB Bearer Capability indicating Number of BearerSupported. In response to the message received from the eNodeB, the MMEmay send to the eNodeB a response message (e.g. ENB CONFIGURATION UPDATEACKNOWLEDGE) comprising an information element indicating MME capabilityof supported number of bearers. As an example, the MME may send to theeNodeB a node level message (e.g. MME CONFIGURATION UPDATE) indicatingMME capability of supported number of bearers. In response to themessage received from the MME, the eNodeB may send to the MME a responsemessage (e.g. MME CONFIGURATION UPDATE ACKNOWLEDGE) comprising aninformation element indicating eNodeB capability of supported number ofbearers.

An SGW may receive from a PGW, a node level message comprising aninformation element indicating PGW capability of supported number ofbearers as per PGW. As an example, the PGW may send to the SGW an EchoRequest message, comprising BEARER CAPABILITY of supporting 15 bearers.FIG. 11A is an example diagram depicting a list of information elementsin an Echo Request message; FIG. 11B is an example diagram depicting theinformation element definition of Sending Node Feature comprised in theEcho Request message; FIG. 12 is an example diagram depicting theexample Supported-Features values comprised in the Sending Node Featureinformation element, and a value of BEARER CAPABILITY may be used toindicate capability of network element (e.g. MME, SGW, PGW) for totalsupported number of bearers (e.g. 15 bearers). In response to themessage received, the SGW may reply to the PGW a node level messagecomprising an information element indicating SGW capability of supportednumber of bearers. As an example, the SGW may send to the PGW an EchoResponse message, comprising BEARER CAPABILITY of supporting 11 bearers.As an example, the SGW may send to the PGW a node level message (e.g.Echo Request) indicating SGW capability of supported number of bearers;and the PGW may reply to SGW a node level message (e.g. Echo Response)indicating PGW capability of supported number of bearers.

The SGW may determine SGW&PGW capability of supported number of bearers,based on at least one or more of the following capabilities: SGWcapability of supported number of bearers, and PGW capability ofsupported number of bearers. As an example, the SGW may compare the SGWcapability of supported number of bearers with the PGW capability ofsupported number of bearers and may take the lower supported number ofbearer as the SGW&PGW capability of supported number of bearers. Forexample, PGW capability of supported number of bearers is 15, SGWcapability of supported number of bearers is 11, the SGW may determinethat the SGW&PGW capability of supported number of bearers is 11.

An MME may receive from an SGW, a node level message comprising at leastone information element indicating one or more of the followingcapabilities: SGW capability of supported number of bearers, PGWcapability of supported number of bearers; and/or SGW&PGW capability ofsupported number of bearers. As an example, the MME may receive from theSGW an Echo Request message, comprising BEARER CAPABILITY of SGWsupporting 11 bearers, BEARER CAPABILITY of PGW supporting 15 bearers,and/or BEARER CAPABILITY of SGW&PGW supporting 11 bearers. In responseto the message received, the MME may reply to the SGW a node levelmessage comprising an information element indicating MME capability ofsupported number of bearers. As an example, the MME may send to the SGWan Echo Response message, comprising BEARER CAPABILITY of supporting 15bearers.

The MME may determine network capability of supported number of bearersper UE and/or per IP-CAN session and/or per APN, based on at least oneor more of the following capabilities: eNodeB capability of supportednumber of bearers, MME capability of supported number of bearers, SGWcapability of supported number of bearers, PGW capability of supportednumber of bearers, and/or SGW&PGW capability of supported number ofbearers. As an example, the MME may compare the eNodeB capability ofsupported number of bearers, MME capability of supported number ofbearers, SGW capability of supported number of bearers, PGW capabilityof supported number of bearers, and/or SGW&PGW capability of supportednumber of bearers. In an example, the MME and may take the lowersupported number of bearer as the network capability of supported numberof bearers. For example, eNodeB capability of supported number ofbearers is 15, MME capability of supported number of bearers is 11, SGWcapability of supported number of bearers is 11, PGW capability ofsupported number of bearers is 15, SGW&PGW capability of supportednumber of bearers may be 15, the MME may determine that the networkcapability of supported number of bearers is 11. The MME may send to theSGW a node level message (e.g. Echo Request) comprising the networkcapability of supported number of bearers, and in response to themessage received from the MME, the SGW may send to the PGW a node levelmessage (e.g. Echo Request) comprising the network capability ofsupported number of bearers.

A UE may initiate an attach procedure by sending to the eNodeB an attachrequest message comprising one or more of the following parameters: IMSIor old GUTI, Old GUTI type, last visited TAI (if available), UE corenetwork capability, attach type, ESM message container, additional GUTI,P-TMSI signature, and/or MS network capability. The message may betogether with RRC parameters indicating the Selected Network and the oldGUMMEI. The attach request message may comprise a UE capability ofsupported number of bearers, as an example, the UE capability ofsupported number of bearers may be 15. In response to the messagereceived from the UE, the eNodeB may forward to the MME the receivedattach request message comprising the UE capability of supported numberof bearers.

In response to the message received from the eNodeB, the MME may takeone or more of actions. In an example action, the MME may compare the UEcapability of supported number of bearers with the network capability ofsupported number of bearers; As an example, the PGW may compare the UEcapability of supported number of bearers with the network capability ofsupported number of bearers, and take the lower supported number ofbearer as UE & network capability or system capability of supportednumber of bearers per UE and/or per IP-CAN session and/or per APN. Forexample, the UE capability of supported number of bearers is 15 and thenetwork capability of supported number of bearers is 11, the PGW maydetermine the UE & network capability or system capability of supportednumber of bearers per UE and/or per APN and/or per IP-CAN session as 11.In an example action, the MME may allocate a Bearer Id. In an exampleaction, the MME may selec a gateway (e.g. SGW), and send to the SGW amessage, e.g. a create session request message comprising one or more ofthe following parameters: IMSI, MME TEID for control plane, RAT type,PGW address, PDN Address, default EPS bearer QoS, PDN type, subscribedAPN-AMBR, APN, EPS bearer Id, and/or protocol configuration options. Asan example, the message may comprise the UE capability of supportednumber of bearers if the UE capability of supported number of bearers isdifferent with the network capability of supported number of bearers. Asan example, the message may comprise the UE capability of supportednumber of bearers whatever the UE capability of supported number ofbearers is different with the network capability of supported number ofbearers or not. As an example, the message may comprise the UE & networkcapability or system capability of supported number of bearers.

In response to the message received from the MME, the SGW may create anew entry in its EPS Bearer table and store the information receivedfrom the MME (e.g. UE capability of supported number of bearers), andmay send to a PGW a create session request message comprising one ormore of the following parameters: IMSI, Serving GW address for the userplane, Serving GW TEID of the user plane, Serving GW TEID of the controlplane, RAT type, default EPS bearer QoS, PDN Type, PDN address,subscribed APN-AMBR, APN and/or bearer Id. The message may comprise theUE capability of supported number of bearers if received from the MME.As an example, the message may comprise the UE & network capability orsystem capability of supported number of bearers.

In response to the message received from the SGW, the PGW may create anew entry in its EPS bearer context table, store the informationreceived from the SGW (e.g. UE capability of supported number ofbearers), and generates a Charging Id for the default bearer. The newentry allows the PGW to route user plane PDUs between the S-GW and thepacket data network. As an example, the PGW may create bearer(s) basedon UE & network capability or system capability of supported number ofbearers if received from the SGW. As an example, the PGW may createbearer(s) based on one or more of the following capabilities: the UEcapability of supported number of bearers, and the network capability ofsupported number of bearers. As an example, the PGW may compare the UEcapability of supported number of bearers with the network capability ofsupported number of bearers and take the lower supported number ofbearer as UE & network capability or system capability of supportednumber of bearers per UE and/or per IP-CAN session and/or per APN. Forexample, the UE capability of supported number of bearers is 15 and thenetwork capability of supported number of bearers is 11, the PGW maydetermine the UE & network capability or system capability of supportednumber of bearers per UE and/or per APN and/or per IP-CAN session as 11.The PGW may create a bearer (e.g. creating a dedicated bearer) based onthe UE & network capability or system capability of supported number ofbearers, e.g. not exceed the UE & network capability or systemcapability of supported number of bearers when creating a new bearer.The PGW may send to a PCRF a message (e.g. IP-CAN session establishmentrequest) to get the policy (s) for an IP-CAN session.

In response to the message received from the PGW, the PCRF may send tothe PGW a message (e.g. IP-CAN session establishment response) byproviding the policy (s) applied to service data flow(s) and/or theIP-CAN session. In response to the message received from the SGW, thePGW may return to the SGW a create session response message comprisingone or more of the following parameters: PGW address for the user plane,PGW TEID of the user plane, PGW TEID of the control plane, PDN Type, PDNAddress, EPS bearer Id, EPS bearer QoS, charging Id, and/or APN-AMBR).The PGW may correlate the PGW Address for the user plane and PGW TEID ofthe user plane, with the Serving GW Address for the user plane andServing GW TEID of the user plane received from SGW. The correlatedinformation may be used as the user plane tunnel address between the SGWand the PGW.

In response to the message received from the PGW, the SGW may correlatethe Serving GW Address for the user plane and Serving GW TEID of theuser plane, with the PGW address for the user plane and PGW TEID of theuser plane received from the PGW. In response to the message receivedfrom the MME, the SGW may response to the MME a create session responsemessage comprising at least one of: PDN Type, PDN address, SGW addressfor User Plane, SGW TEID for User Plane, SGW TEID for control plane, EPSbearer Id, EPS bearer QoS, PGW address and TEID (GTP-based S5/S8) at thePGW for uplink traffic and/or APN-AMBR. The MME may send to the eNodeBan attach accept message comprising one or more of the followingparameters: GUTI, TAI List, and/or session management request message,where the session management request message may comprise one or more ofthe following parameters: APN, PDN type, PDN address, EPS bearerIdentity, protocol configuration options, header compressionconfiguration. The attach accept message may be contained in an S1_MMEcontrol message initial context setup request. The S1-AP initial contextsetup request message may also comprise the EPS bearer QoS, the UE-AMBR,EPS bearer Identity, as well as the TEID at the Serving GW used for userplane and the address of the Serving GW for user plane. The attachaccept message may comprise the network capability of supported numberof bearers. As an example, the message may comprise the networkcapability of supported number of bearers if the UE capability ofsupported number of bearers is different with the network capability ofsupported number of bearers. As an example, the message may comprise thenetwork capability of supported number of bearers whatever the UEcapability of supported number of bearers is different with the networkcapability of supported number of bearers or not.

In response to the message received from the MME, the eNodeB may takeone or more of actions. In an example action, the eNodeB may store theinformation received from the MME. The eNodeB may use the SGW addressfor User Plane, SGW TEID for User Plane for the uplink data forwarding.In an example action, the eNodeB may send to the UE a RRC connectionreconfiguration comprising EPS radio bearer identity and/or the networkcapability of supported number of bearers. The UE may create bearer(s)(e.g. UE requested PDN connectivity, UE requested bearer resourcemodification) based on one or more of the following capabilities: the UEcapability of supported number of bearers, and the network capability ofsupported number of bearers. As an example, the UE may compare the UEcapability of supported number of bearers with the network capability ofsupported number of bearers and take the lower supported number ofbearer as UE & network capability or system capability of supportednumber of bearers per UE and/or per IP-CAN session and/or per APN. Forexample, the UE capability of supported number of bearers is 15 and thenetwork capability of supported number of bearers is 11, the UE maydetermine UE & network capability or system capability of supportednumber of bearers per UE and/or per APN and/or per IP-CAN session as 11.The UE may create a bearer (e.g. UE requested PDN connectivity) based onthe UE & network capability or system capability of supported number ofbearers, e.g. not exceed the UE & network capability or systemcapability of supported number of bearers when creating a new bearer.

In response to the message received from the eNodeB, the UE may responseto the eNodeB an RRC connection reconfiguration complete message. Inresponse to the message received from the UE, the eNodeB may send to theMME an initial context response message. The initial context responsemessage may comprise the TEID of the eNodeB and the address of theeNodeB used for downlink traffic on the S1_U reference point. The eNodeBmay correlate the TEID of the eNodeB and the address of the eNodeB, withthe SGW address for User Plane and the SGW TEID for User Plane receivedfrom the MME. The correlated information may be used as the user planetunnel address between the eNodeB and the SGW.

The UE may send to the eNodeB a direct transfer message, the message maycomprise an attach complete message which may comprise one or more ofthe following parameters: EPS Bearer Identity, NAS sequence number,and/or NAS-MAC. In response to the message received from the UE, theeNodeB may forward to the MME the attach complete message in an uplinkNAS transport message. In response to the message received from theeNodeB, the MME may send to SGW a modify bearer request messagecomprising at least one of: EPS bearer Identity, eNodeB address, eNodeBTEID, handover indication, and/or presence reporting area information.The SGW may correlate the TEID of the eNodeB and the address of theeNodeB, with the SGW address for user plane and the SGW TEID for userplane. In response to the message received from the MME, the SGW maysend to the MME a modify bearer response message comprising the EPSbearer Identity. The SGW may send its buffered downlink packets to theeNodeB.

In an example, by node level signaling with one or more target eNodeBs,a source eNodeB may derive/get the target eNodeB(s) capability ofsupported number of bearers. The source eNodeB may select a targeteNodeB for handover based on the target eNodeB capability of supportednumber of bearers. FIG. 7 shows an example call flow which may compriseone or more actions.

A first eNodeB 1 may receive from one or more second eNodeBs, a message(e.g. node level message as per eNodeB, or session level message as perIP-CAN session, or UE level message as per UE, APN level message as perAPN) comprising an information element indicating second eNodeBcapability of supported number of bearers. As an example, the eNodeB 1may receive from an eNodeB 2 an ENB CONFIGURATION UPDATE messagecomprising an information element indicating eNodeB 2 capability ofsupported number of bearers. In response to the message received fromthe second eNodeB(s), the first eNodeB 1 may send to the secondeNodeB(s) a response message. As an example, the eNodeB 1 may responseto eNodeB 2 with an ENB CONFIGURATION UPDATE ACKNOWLEDGE messagecomprising an information element indicating eNodeB 1 capability ofsupported number of bearers.

As an example, the first eNodeB may send to one or more second eNodeBs amessage (e.g. ENB CONFIGURATION UPDATE) comprising an informationelement indicating first eNodeB capability of supported number ofbearers. In response to the message received from the first eNodeB, thesecond eNodeB(s) may send to the first eNodeB a response message (e.g.ENB CONFIGURATION UPDATE ACKNOWLEDGE) comprising an information elementindicating second eNodeB capability of supported number of bearers. Asan example, a first MME 1 may receive from one or more second MMEs amessage comprising an information element indicating second MMEcapability of supported number of bearers. As an example, the first MME1 may send to one or more second MMEs a message comprising aninformation element indicating first MME 1 capability of supportednumber of bearers. As an example, a second MME 2 may receive from one ormore second SGWs a message comprising an information element indicatingsecond SGW capability of supported number of bearers. As an example, thesecond MME 2 may send to one or more second SGWs a message comprising aninformation element indicating second MME 2 capability of supportednumber of bearers.

The first eNodeB 1 may receive from a UE a measurement report messagecomprising block error rate, transmit power and other UE-basedparameters. The first eNodeB 1 may decide to initiate an S1-basedhandover to a second eNodeB. The first eNodeB 1 may select a secondeNodeB for the handover based on at least the second eNodeB capabilityof supported number of bearers and/or measurement report received fromthe UE, as an example, a second eNodeB 2 may be selected for thehandover. The first eNodeB 1 may send to a first MME 1 a handoverrequired message comprising one or more of the following parameters:direct forwarding path availability, source to target transparentcontainer, target eNodeB Identity (e.g. second eNodeB 2 identity), CSGID, CSG access mode, target TAI, and/or S1AP Cause; wherein directforwarding path availability may indicate whether direct forwarding isavailable from the first eNodeB 1 to the second eNodeB 2.

In response to the message received from the first eNodeB 1, the firstMME 1 may determine an MME relocation and may select a second MME 2based on at least the second MME 2 capability of supported number ofbearers. The first MME 1 may send to the second MME 2 a forwardrelocation request message comprising one or more of the followinginformation: MME UE context, source to target transparent container, RANcause, target eNodeB Identity, CSG ID, CSG membership indication, targetTAI, MS Info change reporting action (if available), CSG informationreporting action (if available), UE time zone, direct forwarding flag,serving network, and/or local home network id. In response to themessage received from the first MME 1, the second MME 2 may determine anSGW relocation and may select a second SGW 2 based on at least thesecond SGW 2 capability of supported number of bearers. The second MME 2may send to the second SGW 2 create session request message comprisingone or more of the following information: bearer context(s) with PDN GWaddresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-basedS5/S8) at the PDN GW(s) for uplink traffic, serving network, and/or UEtime zone per PDN connection to the second SGW 2. The second SGW 2 mayallocate the S-GW addresses and TEIDs for the uplink traffic on S1_Ureference point (one TEID per bearer).

In response to the message received from the second MME 2, the secondSGW 2 may send to the second MME 2 a create session response comprisingone or more of the following information: Serving GW addresses anduplink TEID(s) for user plane. The second MME 2 may send to the secondeNodeB 2 a handover request message comprising one or more of thefollowing information: EPS bearers to setup, AMBR, S1AP cause, source totarget transparent container, CSG ID, CSG membership indication,handover restriction list. For each EPS bearer, the EPS bearers to setupmay comprise Serving GW address and uplink TEID for user plane, and EPSbearer QoS. In response to the message received from the second MME 2,the second eNodeB 2 may send to the second MME 2 a handover requestacknowledge comprising one or more of the following information: EPSbearer setup list, EPS Bearers failed to setup list Target to Sourcetransparent container. The EPS bearer setup list may include a list ofaddresses and TEIDs allocated at the second eNodeB 2 for downlinktraffic on S1-U reference point (one TEID per bearer) and addresses andTEIDs for receiving forwarded data if necessary.

If indirect forwarding applies and the Serving GW is relocated, thesecond MME 2 may set up forwarding parameters by sending to the secondSGW 2 a create indirect data forwarding tunnel request comprising secondeNodeB 2 addresses and TEIDs for forwarding. In response to the messagereceived from the second MME 2, the second SGW 2 may send to the secondMME a create indirect data forwarding tunnel response message comprisingtarget Serving GW addresses and TEIDs for forwarding. If the MME hasbeen relocated, the second MME 2 may send to the first MME 1 a forwardrelocation response message comprising one or more of the followinginformation: cause, target to source transparent container, Serving GWchange indication, EPS bearer setup list, addresses and TEIDs). Forindirect forwarding, this message may include Serving GW address andTEIDs for indirect forwarding (source or target). Serving GW changeindication indicates a new Serving GW (e.g. SGW 2) has been selected. Ifindirect forwarding applies, the first MME 1 may send to the first SGW 1a create indirect data forwarding tunnel request message comprisingaddresses and TEIDs for forwarding. If the Serving GW is relocated, thecreate an indirect data forwarding tunnel request message may includethe tunnel identifier to the second SGW 2.

In response to the message received from the first MME 1, the first SGW1 may send to the first MME 1 create indirect data forwarding tunnelresponse comprising Serving GW addresses and TEIDs for forwarding. Inresponse to the message received from the first SGW 1, the first MME 1may send to the first eNodeB 1 a handover command message comprising oneor more of the following information: target to source transparentcontainer, bearers subject to forwarding, bearers to release. Thebearers subject to forwarding may comprise list of addresses and TEIDsallocated for forwarding. The bearers to release may comprise the listof bearers to be released. In response to the message received from thefirst MME 1, the eNodeB 1 may construct a handover command message byusing the target to source transparent container, and the eNodeB 1 maysend the message to the UE. Upon reception of this message, the UE mayremove any EPS bearers for which it did not receive the correspondingEPS radio bearers in the target cell (e.g. in the second eNodeB 2).

In an example, an MME may receive from an SGW a first message indicatinga request to create a bearer, wherein the first message may comprise atleast one of: IMSI, EPS Bearer QoS of the bearer, TFT of the bearer,S1-TEID of the bearer and/or PDN GW TEID of the bearer (GTP-basedS5/S8). The MME may determine that a number of bearers exceeds aconfigured supported number of bearers if the bearer is created. The MMEmay send to the SGW and in response to the determining, a responsemessage comprising a cause information element indicating a failure ofcreating the bearer because of exceeding the supported number ofbearers.

In an example, an MME may receive from an SGW a first message indicatinga request to create a bearer, wherein the first message may comprise atleast one of: IMSI, EPS Bearer QoS of the bearer, TFT of the bearer,S1-TEID of the bearer and/or PDN GW TEID of the bearer (GTP-basedS5/S8). The MME may send to an eNB, a second message indicating arequest to create the bearer. The MME may receive from the eNB, aresponse message to the second message, the response message indicatingthe bearer is rejected by the eNB because a number of bearers exceeds aconfigured supported number if the bearer is created. The MME may sendto the SGW and in response to the determining, a response messagecomprising a cause information element indicating a failure of creatingthe bearer because of exceeding the supported number of bearers. In anexample, the eNB may send to a wireless device, a third messagecomprising configuration parameters of the bearers (e.g. requestcreating a bearer), and the eNB may receive from the wireless device, afourth message comprising at least one parameter indicating that thebearer is rejected.

In an example, an MME may receive from an SGW, a first messageindicating a request to create a bearer, wherein the first message maycomprise at least one of: IMSI, EPS Bearer QoS of the bearer, TFT of thebearer, S1-TEID of the bearer and/or PDN GW TEID of the bearer(GTP-based S5/S8). The MME may determine whether the bearer can becreated with the EPS Bearer QoS of the bearer. The MME may send to theSGW and in response to the determining, a response message comprising acause information element indicating a failure of creating the bearerbecause the EPS Bearer QoS of the bearer cannot be supported.

In an example, an MME may receive from an eNB, a first messagecomprising at least one eNB capability parameter indicating that the eNBsupports up to a first number of bearers per wireless device. The MMEmay send to the eNB, a second message comprising at least one MMEcapability parameter indicating that the MME supports up to a secondnumber of bearers per wireless device. The MME may receive from an SGW,a third message comprising at least: one SGW capability parameterindicating that the SGW supports up to a third number of bearers perwireless device, and/or one PGW capability parameter indicating that thePGW supports up to an eighth number of bearers per wireless device. TheMME may send to the SGW, a fourth message comprising the at least oneMME capability parameter indicating that the MME supports up to thesecond number of bearers per wireless device. The MME may determine thata network capability that a network supports up to a fourth number ofbearers per wireless device, based on at least one or more of thefollowing: the at least one eNB capability parameter; the at least oneMME capability parameter; the at least one SGW capability parameter; theat least one PGW capability parameter; and/or the at least one SGW&PGWcapability parameter. The MME may send to the SGW, a fifth messagecomprising the at least one network capability parameter indicating thatthe network supports up to the fourth number of bearers per wirelessdevice.

In an example, an MME may receive from a wireless device and via an eNB,a sixth message comprising at least one wireless device capabilityparameter indicating that the wireless device supports up to a fifthnumber of bearers. The MME may determine a sixth number of bearers basedon the fifth number of bearers and a fourth number of bearers supportedby a network. The MME may send to an SGW, a seventh message comprisingthe sixth number bearers. In an example, the MME may receive from theSGW, a response message to the seventh message indicating that a sessionis successfully created. The MME may send to the wireless device and viathe eNB, an eighth message indicating a request for initial contextsetup, wherein the eighth message may comprise the fourth number ofbearers supported by the network if the fourth number is different fromthe fifth number. In an example, the sixth message may indicate arequest to attach to the network. In an example, the seventh message mayindicate a request to create a session. In an example, the secondmessage may be transmitted in response to the first message. In anexample, the sixth number may be equal to a smaller of the fourth numberand the fifth number if the fourth number is different from the fifthnumber; and equal to the fourth number if the fourth number is equal tothe fifth number.

In an example, the SGW may receive from a PGW, a ninth messagecomprising at least one PGW capability parameter indicating that the PGWsupports up to an eighth number of bearers per wireless device. The SGWmay determine, an SGW&PGW capability that a SGW&PGW supports up to aninth number of bearers per wireless device, based on at least one ormore of the following: the eighth number of bearers per wireless device;and an SGW number of bearers per wireless device.

In an example, a first eNB may send to a second eNB, a first messagecomprising at least one first eNB capability parameter indicating thatthe first eNB supports up to a first number of bearers per wirelessdevice. The first eNB may receive from the second eNB, a second messagecomprising at least one second eNB capability parameter indicating thatthe second eNB supports up to a second number of bearers per wirelessdevice. The first eNB may receive from a wireless device, a thirdmessage comprising at least one measurement report. The first eNB maydetermine a handover to a second eNB based on: the at least onemeasurement report; and/or the least one second eNB capabilityparameter. The first eNB may send to a first MME, a fourth messageindicating a handover request. The first eNB may receive from the firstMME a fifth message indicating acceptance of the handover request. Thefirst eNB may send to the wireless device, a sixth message indicating acommand to initiate a handover by the wireless device.

According to various embodiments, a device such as, for example, awireless device, off-network wireless device, a base station, and/or thelike, may comprise one or more processors and memory. The memory maystore instructions that, when executed by the one or more processors,cause the device to perform a series of actions. Embodiments of exampleactions are illustrated in the accompanying figures and specification.Features from various embodiments may be combined to create yet furtherembodiments.

FIG. 13 is an example flow diagram as per an aspect of an embodiment ofthe present disclosure. At 1310, a first base station may receive afirst message from at least one second base station. The first messagemay comprise capability information indicating a number of bearerssupported by the at least one second base station. At 1320, the firstbase station may receive a measurement report from a wireless device, ameasurement report comprising a received power of a cell of the secondbase station. At 1330, the first base station may determine a handoverto the cell based on the measurement report and the number of bearerssupported by the at least one second base station. At 1340, the firstbase station may send a handover request to the at least one second basestation in response to the determining the handover.

FIG. 14 is an example flow diagram as per an aspect of an embodiment ofthe present disclosure. At 1410, the first base station may send asecond message to a first mobility management entity requesting ahandover. The second message may comprise an identity of the at leastone second base station. At 1420, the first mobility management entitymay receive a third message from at least one second mobility managemententity. The third message may comprise capability information indicatinga number of bearers supported by the at least one second mobilitymanagement entity. At 1430, the first mobility management entity maydetermine a relocation of the first mobility management entity to the atleast one second mobility management entity, based on at least thenumber of bearers supported by the at least one second mobilitymanagement entity. At 1440, the first mobility management entity maysend a forward relocation request message to the at least one secondmobility management entity. The forward relocation request message maycomprise the identity of the at least one second base station. At 1450,the at least one second mobility management entity may determine, by arelocation of a first serving gateway in response to the forwardrelocation request message. At 1460, the at least one second mobilitymanagement entity may select at least one second serving gateway, basedon at least a number of bearers supported by the at least one secondserving gateway.

According to an example embodiment, the first mobility management entitymay receive a fourth message from the at least one second servinggateway. The fourth message may comprise capability informationindicating a number of bearers supported by the at least one secondserving gateway. According to an example embodiment, the at least onesecond mobility management entity may send to the at least one secondserving gateway, a create session request message requesting creation ofa session. According to an example embodiment, the at least one secondmobility management entity may receive a create session response messagefrom the at least one second serving gateway in response to the createsession request message. According to an example embodiment, the atleast one second mobility management entity may send a handover requestmessage to the at least one second base station. According to an exampleembodiment, the at least one second mobility management entity mayreceive a handover request acknowledge message from the at least onesecond base station in response to the handover request message.According to an example embodiment, the at least one second mobilitymanagement entity may send a forward relocation response to the firstmobility management entity. According to an example embodiment, thefirst base station may receive a first handover command message from thefirst mobility management entity in response to the second message.According to an example embodiment, the first base station may send asecond handover command message to the wireless device in response tothe first handover command message. According to an example embodiment,the second message may be a handover required message. According to anexample embodiment, the measurement report may comprise a block errorrate. According to an example embodiment, the measurement report maycomprise a transmit power. According to an example embodiment, themeasurement report may comprise other UE-based parameters. According toan example embodiment, the first message may be an ENB CONFIGURATIONUPDATE message.

FIG. 15 is an example flow diagram as per an aspect of an embodiment ofthe present disclosure. At 1510, a wireless device may receive a firstmessage from a mobility management entity through a base station. Thefirst message may indicate an attach accept. The first message maycomprise a network capability of supported number of bearers. At 1520,the wireless device may determine a system capability of supportednumber of bearers based on the network capability of supported number ofbearers and UE capability of supported number of bearers. At 1530, thewireless device may request for establishment of a new bearer based onthe system capability of supported number of bearers.

FIG. 16 is an example flow diagram as per an aspect of an embodiment ofthe present disclosure. At 1610, a base station may receive a firstmessage from a mobility management entity. The first message may requestcreation of a new bearer. The first message may comprise an EPS beareridentity. At 1620, the base station may determine, based on capabilityof supported number of bearers of the base station whether to accept orreject the request. At 1630, the base station may send a second messageto the mobility management entity in response to the first message. Thesecond message may comprise at least one information element indicatingthat the creating the new bearer failed because of exceeding supportednumber of bearers.

In this specification, “a” and “an” and similar phrases are to beinterpreted as “at least one” and “one or more.” In this specification,the term “may” is to be interpreted as “may, for example.” In otherwords, the term “may” is indicative that the phrase following the term“may” is an example of one of a multitude of suitable possibilities thatmay, or may not, be employed to one or more of the various Examples. IfA and B are sets and every element of A is an element of B, A is calleda subset of B. In this specification, only non-empty sets and subsetsare considered. For example, possible subsets of B={cell1, cell2} are:{cell1}, {cell2}, and {cell1, cell2}.

In this specification, various Examples are disclosed. Limitations,features, and/or elements from the disclosed example Examples may becombined to create further Examples within the scope of the disclosure.

In this specification, various Examples are disclosed. Limitations,features, and/or elements from the disclosed example Examples may becombined to create further Examples within the scope of the disclosure.

In this specification, parameters (Information elements: IEs) maycomprise one or more objects, and one of those objects may comprise oneor more other objects. For example, if parameter (IE) N comprisesparameter (IE) M, and parameter (IE) M comprises parameter (IE) K, andparameter (IE) K comprises parameter (information element) J, then, forexample, N comprises K, and N comprises J. In an example, when one ormore messages comprise a plurality of parameters, it implies that aparameter in the plurality of parameters is in at least one of the oneor more messages, but does not have to be in one of the one or moremessages.

Many of the elements described in the disclosed Examples may beimplemented as modules. A module is defined here as an isolatableelement that performs a defined function and has a defined interface toother elements. The modules described in this disclosure may beimplemented in hardware, software in combination with hardware,firmware, wetware (e.g. hardware with a biological element) or acombination thereof, some of which are behaviorally equivalent. Forexample, modules may be implemented as a software routine written in acomputer language configured to be executed by a hardware machine (suchas C, C++, Fortran, Java, Basic, Matlab or the like) or amodeling/simulation program such as Simulink, Stateflow, GNU Octave, orLabVIEWMathScript. Additionally, it may be possible to implement modulesusing physical hardware that incorporates discrete or programmableanalog, digital and/or quantum hardware. Examples of programmablehardware comprise: computers, microcontrollers, microprocessors,application-specific integrated circuits (ASICs); field programmablegate arrays (FPGAs); and complex programmable logic devices (CPLDs).Computers, microcontrollers and microprocessors are programmed usinglanguages such as assembly, C, C++ or the like. FPGAs, ASICs and CPLDsare often programmed using hardware description languages (HDL) such asVHSIC hardware description language (VHDL) or Verilog that configureconnections between internal hardware modules with lesser functionalityon a programmable device. Finally, it needs to be emphasized that theabove mentioned technologies are often used in combination to achievethe result of a functional module.

The disclosure of this patent document incorporates material which issubject to copyright protection. The copyright owner has no objection tothe facsimile reproduction by anyone of the patent document or thepatent disclosure, as it appears in the Patent and Trademark Officepatent file or records, for the limited purposes required by law, butotherwise reserves all copyright rights whatsoever.

While various Examples have been described above, it should beunderstood that they have been presented by way of example, and notlimitation. It will be apparent to persons skilled in the relevantart(s) that various changes in form and detail can be made thereinwithout departing from the spirit and scope. In fact, after reading theabove description, it will be apparent to one skilled in the relevantart(s) how to implement alternative Examples. Thus, the present Examplesshould not be limited by any of the above described exemplary Examples.In particular, it should be noted that, for example purposes, the aboveexplanation has focused on the example(s) using 5G AN. However, oneskilled in the art will recognize that Examples of the invention may beimplemented in a system comprising one or more legacy systems or LTE.The disclosed methods and systems may be implemented in wireless orwireline systems. The features of various Examples presented in thisinvention may be combined. One or many features (method or system) ofone Example may be implemented in other Examples. A limited number ofexample combinations are shown to indicate to one skilled in the art thepossibility of features that may be combined in various Examples tocreate enhanced transmission and reception systems and methods.

In addition, it should be understood that any figures which highlightthe functionality and advantages, are presented for example purposes.The disclosed architecture is sufficiently flexible and configurable,such that it may be utilized in ways other than that shown. For example,the actions listed in any flowchart may be re-ordered or optionally usedin some Examples.

Further, the purpose of the Abstract of the Disclosure is to enable theU.S. Patent and Trademark Office and the public generally, andespecially the scientists, engineers and practitioners in the art whoare not familiar with patent or legal terms or phraseology, to determinequickly from a cursory inspection the nature and essence of thetechnical disclosure of the application. The Abstract of the Disclosureis not intended to be limiting as to the scope in any way.

Finally, it is the applicant's intent that only claims that include theexpress language “means for” or “step for” be interpreted under 35U.S.C. 112. Claims that do not expressly include the phrase “means for”or “step for” are not to be interpreted under 35 U.S.C. 112.

What is claimed is:
 1. A method comprising: receiving, by a first basestation from at least one second base station, a first messagecomprising a capability parameter indicating a maximum number of bearersper wireless device that can be supported by the at least one secondbase station; receiving, by the first base station from a first wirelessdevice, a measurement report comprising a received power of a cell ofthe second base station; determining, by the first base station, ahandover to the cell based on the measurement report and the maximumnumber of bearers per wireless device that can be supported by the atleast one second base station; and sending, by the first base station tothe at least one second base station, a handover request in response tothe determining the handover.
 2. The method of claim 1, furthercomprising sending, by the first base station to a first mobilitymanagement entity, a second message requesting a handover, the secondmessage comprising an identity of the at least one second base station.3. The method of claim 2, further comprising receiving, by the firstmobility management entity from at least one second mobility managemententity, a third message comprising a second capability parameterindicating a maximum number of bearers per wireless device that can besupported by the at least one second mobility management entity.
 4. Themethod of claim 3, further comprising determining, by the first mobilitymanagement entity, a relocation of the first mobility management entityto the at least one second mobility management entity, based on at leastthe maximum number of bearers per wireless device that can be supportedby the at least one second mobility management entity.
 5. The method ofclaim 4, further comprising sending, by the first mobility managemententity to the at least one second mobility management entity, a forwardrelocation request message comprising the identity of the at least onesecond base station.
 6. The method of claim 5, further comprisingdetermining, by the at least one second mobility management entity, arelocation of a first serving gateway and in response to the forwardrelocation request message.
 7. The method of claim 6 further comprisingselecting, by the at least one second mobility management entity, atleast one second serving gateway, based on at least a maximum number ofbearers per wireless device that can be supported by the at least onesecond serving gateway.
 8. The method of claim 7, further comprisingreceiving, by the first mobility management entity from the at least onesecond serving gateway, a fourth message comprising a third capabilityparameter indicating a maximum number of bearers per wireless devicethat can be supported by the at least one second serving gateway.
 9. Themethod of claim 8, further comprising sending, by the at least onesecond mobility management entity to the at least one second servinggateway, a create session request message requesting creation of asession.
 10. The method of claim 9, further comprising receiving, by theat least one second mobility management entity from the at least onesecond serving gateway and in response to the create session requestmessage, create session response message.
 11. The method of claim 10,further comprising sending, by the at least one second mobilitymanagement entity to the at least one second base station, a handoverrequest message.
 12. The method of claim 11, further comprisingreceiving, by the at least one second mobility management entity fromthe at least one second base station and in response to the handoverrequest message, a handover request acknowledge message.
 13. The methodof claim 12, further comprising sending, by the at least one secondmobility management entity to the first mobility management entity, aforward relocation response.
 14. The method of claim 2, furthercomprising receiving, by the first base station from the first mobilitymanagement entity and in response to the second message, a firsthandover command message.
 15. The method of claim 14, further comprisingsending, by the first base station to the first wireless device and inresponse to the first handover command message, a second handovercommand message.
 16. The method of claim 2, wherein the second messageis a handover required message.
 17. The method of claim 1, wherein themeasurement report comprises a block error rate.
 18. The method of claim1, wherein the measurement report comprises a transmit power.
 19. Themethod of claim 1, wherein the measurement report comprises otherUE-based parameters.
 20. The method of claim 1, wherein the firstmessage is an ENB CONFIGURATION UPDATE message.